Some distributed computing environments, such as Parallel Sysplexes, today provide a non-volatile shared storage device called the coupling facility, that includes multiple storage structures of either the cache or list type. These structures provide unique functions for the operating system and middleware products employed for the efficient operation of a Parallel Sysplex. For example, the cache structures provide directory structures and cross-invalidation mechanisms to maintain buffer coherency for multisystem databases, as well as a fast write medium for database updates. These are used by, for instance, the data sharing versions of DB2 and IMS, offered by International Business Machines Corporation, Armonk, N.Y.
The list structures provide many diverse functions. One such list structure function is to provide for high-performance global locking, and this function is exploited by such products as the IMS Resource Lock Manager (IRLM) and the Global Resource Serialization (GRS) function in OS/390, offered by International Business Machines Corporation, Armonk, N.Y. Another list structure function is to provide a message passing mechanism with storage for maintaining multiple messages on a per system basis and a mechanism for notifying a system of the arrival of new messages. This function is exploited by the XCF component of OS/390, which in turn is exploited by numerous multisystem applications for providing a capability to pass messages between their various instances. A third list structure function is to provide for shared queue structures that can be ordered and accessed by LIFO/FIFO ordering, by key, or by name. Workload Manager (WLM), IMS Shared Message Queues and MQ Series, all offered by International Business Machines Corporation, Armonk, N.Y., are examples of exploiters of this feature. While these functions provide examples of the list structure uses, other uses exist.
Various components of a Parallel Sysplex have been documented in numerous applications/patents, which are listed above and hereby incorporated herein by reference in their entirety. The capabilities defined in some of those patents provide the basic system structure to create and manage cache and list structure instances. Additionally, various of the applications/patents listed above provide extensions to the base functions of the Parallel Sysplex.
Some coupling facility requests can be executed in a synchronous manner or an asynchronous manner. Often, executing a coupling facility request in a CPU-synchronous manner (where the issuing CPU waits for the completion of the synchronous request to the coupling facility) is the most efficient way to process a coupling facility request. Doing so avoids certain undesirable aspects of CPU-asynchronous execution of a coupling facility request, such as: the overhead of processor context-switching (giving up the CPU to another process or unit of work, while the coupling facility request executes asynchronously), overhead of back-end completion processing of system request blocks (SRBs) for the asynchronous request, and latencies associated with the asynchronous nature of the request itself.
However, there are exceptions to this general rule. When a synchronous request takes a long time to complete, for whatever reason, there is a high “opportunity cost” associated with processor cycles on the issuing CPU being wasted, while waiting for the completion of that synchronous request. At some threshold point, in terms of synchronous service time for a request, there is a tradeoff between the cost of driving the request synchronously versus the cost of driving the request a synchronously—shorter synchronous service times favor synchronous execution, longer synchronous service times favor asynchronous execution.
If synchronous coupling facility service times were easily predictable, then simple “rules of thumb” and static tables would suffice to make this tradeoff reasonably well. However, in practice, coupling facility service times vary in response to many factors, including, for instance: workload peaks and valleys, distance between the Central Electronic Complex (CEC) where the operating system is running and the coupling facility, number and type of coupling facility links, amount of data transfer, whether or not the request is duplexed, what type of coupling facility request it is, the machine type of the coupling facility, the number of processors on the coupling facility, whether those coupling facility processors are shared or dedicated, and if shared, how much processing weight is assigned to the coupling facility image, and so on. Furthermore, many of these factors that influence the synchronous coupling facility request service time can change dynamically, so that a coupling facility that is providing good synchronous service time at one moment may provide poor service time at a later point in time, or vice versa. Thus, the rules of thumb and static tables have proven inadequate in determining whether a request is to be processed synchronously or asynchronously.
Based on the foregoing, a need exists for a capability that enables the manner in which a request is to be processed to be determined dynamically. In particular, a need exists for a capability that dynamically determines whether a request is to be processed synchronously or asynchronously. A further need exists for a capability that makes this determination based on observed synchronous service times.